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Chapter 2 


S/36 Memory Management 


You hear conflicting stories when people discuss how the System/36 manages 
memory. Some people maintain that the System/36 is a swapping machine; oth- 
ers say it’s a virtual machine. Many data processing managers believe System/36 
memory architecture is simply a copy of the System/34 with minor changes; 
likewise, many programmers believe the System/36 limits tasks to 64 K 
because the System/34 has this limitation. Misconceptions arise from the lack 
of complete, understandable System/36 memory management information 
available to busy DP managers and programmers. 

Although understanding the low-level details of S/36 memory man- 
agement isn’t essential, it helps you determine whether you have enough 
memory and whether you are using it effectively. And as you learn more 
about S/36 memory and how the system manages it, you can design S/36 pro- 
grams that use memory efficiently. 


Main Memory Organization 

To develop a picture of S/36 memory, look at a diagram of S/36 main memo- 
ry (Figure 2.1). Main memory is organized as eight-bit bytes and varies in size 
from 128 K to 7,168 K, depending on the machine model. Main memory con- 
sists of hundreds of integrated circuit “chips” and represents one of the most 
finite resources of the S/36. Figure 2.1 shows the three areas that comprise 
the contents of main memory: the fixed nucleus, the variable nucleus, and 
the user area. 

The fixed nucleus, which occupies the first 4 K of main memory, con- 
tains variables and data structures needed by all components of the S/36’s 
operating system, the System Support Program (SSP). The S/36’s dual proces- 
sors — the Main Storage Processor (MSP) and the Control Storage Processor 
(CSP) — also use the fixed nucleus to communicate with each other. Because 
the fixed nucleus is permanently set to the same size and content for all S/36 
machines, a programmer or DP manager can do little to influence its effect on 
performance. However, an assembler language programmer can use the data 
stored in the fixed nucleus when writing special-purpose performance mea- 
surement tools (see MMETER Utility, chapter 14.) 

The variable nucleus includes the transient area, virtual page table, 
resident routines, and system queue space. The transient area is 4 K of memo- 
ry set aside for the very few SSP programs that must run in the variable nucle- 
us. These programs are the task attach and detach, disk file open, diskette 












































Performance Tip 


The SSP automatically 
queues up requests 
for the transient area, 
but a high volume of 
I such requests can 
slow performance 

significantly by 

WI] causing many jobs to 

| wait for the transient 

| area. You can reduce 
transient area 





| contention by 

ill designing your 
I applications to 
minimize new jobsteps 
(e.g., by using external 
HI program calls), thus 
| reducing the need for 
task initiation/ 

termination and file 
i | openiclose. Avoiding 
Mii DDM situations that 
NN result in exceptions 
also helps minimize 
} transient area 
| contention (see 
HAH Chapter 3). 
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Figure 2.1 
Main Storage Contents 


Fixed nucleus (4 K) 


Variable nucleus: Transient area (4 K) 
Virtual Page Table (.25-8 K) 
Resident routines (24-48 K) 


System Queue Space (8 K + as required) 


User Area: SSP programs 
User programs 
Task Workspaces 


open, and disk data management exception routines, which run infrequently 
enough so that contention for the transient area does not slow performance. 
The virtual page table is used by the S/36 virtual memory (VM) mechanism 
(described later) to keep the system operating even when memory is over- 
committed (i.e., when more programs are running than can fit in memory at 
one time). Resident routines are a few special SSP programs (disk data man- 
agement and frequently used parts of workstation data management) that, for 
performance reasons, are always kept in main memory. System queue space 
(SQS) is a “pool” of memory set aside for dedicated use by SSP data structures 
needed to control the system. 


Technical Note 


Only one system program at a time can run in the transient area. Because file open/close, 
task attach/detach, and disk data management (DDM) exception handling all run in the 
transient area, SSP must perform these functions serially. For example, while a task such 
as // LOAD jobstep is being started, no files may be opened or closed. Similarly, when 
DDM exceptions occur (e.g., update of a key) no files may be opened or closed, or tasks 
initiated or terminated, until the exception is handled and the transient area becomes free. 


The name “variable nucleus” implies the nature of this region: it varies 
in size with the amount of work performed by the system. The first three com- 
ponents of the variable nucleus don’t actually change size while the machine 
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is running; the amount of memory they occupy depends on the hardware and 
software configuration at IPL. Only the last area, system queue space (SQS), 
ebbs and flows with the varying system load. Because the first three compo- 
nents are “out of your hands,” nothing more need be said about their function. 
On the other hand, your program design and scheduling do affect SQS, so a 
detailed knowledge of the SQS helps you make decisions that improve overall 
system performance. Later, we'll look at characteristics of SQS that are impor- 
tant from a performance standpoint. 

The last, and usually largest, area of main memory is the user area. 
User programs, most SSP programs, file buffers, screen formats, and other 
objects reside here. One truism applied to computers in general, and the user 
area in particular, is: “You can’t have too much main memory.” 

Effective memory management rests on your understanding of a few 
fundamental concepts: real memory, translated memory, and virtual memory. 
To grasp these ideas, let’s look at main memory from a different angle. 


Memory Concepts 

Figure 2.2 depicts the main memory address space for the S/36. Memory 
addressing is the practice of assigning to each location of computer memory a 
unique address, and using that address when referring to the contents of that 
location. The S/36 follows the popular convention of dividing memory into 
eight-bit bytes, each with a unique numeric address starting with zero. The 
number of bytes that byte-addressable memory may contain depends on the 


Figure 2.2 
System/36 Real Storage Organization 
Each page contains 2 K 


Decimal 
Address 


0 
32,768 
65,536 
99,304 


8,257,536 
8,290,304 
8,323,072 
8,355,840 


Performance Tip 


Adding additional 
memory often drasti- 
cally reduces interac- 
tive response times, 
making it the easiest 
and cheapest way to 
boost performance, 
especially given the 
availability of inex- 
pensive used memory 
(see Chapter 5). 


reserved for translated address 
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: size of the largest allowable address. On the S/36, a memory address is three 

bytes long, or 24 bits. The first bit of every address is set aside for a special 
purpose, leaving 23 bits to contain the address. The largest number that can 

| The 5360 ModelDis be represented by 23 binary bits is 8,388,607, so the S/36 can theoretically 
| generally regardedas_ = have 8,388,608 bytes in its memory (remember, the first address is 0, not 1). 
| pees ere These locations, or bytes, of memory, each with its unique address, make up 
| address space of the real memory — all the memory that physically exists. The range of addresses, 
Model D supportsan from 0 through 8,388,607, is the real address space. the entire set of unique 

8th MB. See Chapter5 memory locations available to the machine. The term real memory is used to 
for information about differentiate between memory that is available on the hardware and memory 
adding an 8thMBof = that programs and programmers are /ed to believe is available (more on this 


gpd hab 4 type of memory later in the discussion of virtual memory). 











Fragmentation 

| When you try to apply the real memory viewpoint in a multitasking system, 
problems arise, the worst of which is fragmentation. Figure 2.3 shows how 
Hi this problem develops. 

In Figure 2.3a, a hypothetical computer with 128 K of memory is run- 
ning four programs that consume a total of 124 K. After programs B and D fin- 
ish running, they release their memory, leaving two 24 K “holes” in the 128 K 
address space (Figure 2.3b). Later, the computer tries to run program E, which 
requires 32 K of memory (Figure 2.3c). Although a total of 48 K is available, 
| the program is unable to run because available memory is split into two 24 K 
| | pieces. Program E must wait for either program A or C to end before it can 
| 








| obtain enough unbroken, or contiguous, memory. Because the usable address 

| space is fragmented, program execution is delayed and perfectly good memo- 
ty is wasted. Memory fragmentation worsens quickly in a busy computer sys- 
tem, causing system performance to drop off dramatically. 





Solving Fragmentation 

Hl One solution to fragmentation is allowing programs to run in noncontiguous 
blocks of memory. The S/36 accomplishes this using addresses that do not 
directly correspond to real memory addresses but must be translated by spe- 
cial hardware into real addresses, hence the term translated addressing. Trans- 
lated addresses appear to the executing program to represent contiguous 

memory locations. 

! Here’s how address translation works. The S/36 groups bytes of real 

memory into 2 K units called pages (as you saw in Figure 2.2), each with a 

| unique number from 0 to 4095. Figure 2.4 shows the program PROG A bro- 

ken up into pages. Note that in main memory PROG A is not just fragmented 

i — its logical pages are out of order. The fourth logical page of PROGA physi- 


i) cally appears before the first logical page. Before such a fragmented program 
“ — lc 
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; Figure 2.3 
How Memory Fragmentation Occurs 


Main Storage Main Storage Main Storage 
Program A 


Program B 
Program C 


Program D 
Unused Memory 


Figure 2.4 
How the System/36 Solves Fragmentation 


Page 
Frame # Main Storage 


Prog A page 4 2K 
Prog A page 5 2K 
Prog A page 3 2K 
Prog A page 2 2K 
Prog A page 1 2K 
Prog A page 0 2K 


Address 
Translation 
Register Array 
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can run, a mechanism must rearrange the physical pages into theircorrect 
logical order. 

The S/36 contains a special array of hardware registers, called address 
translation registers (ATRs). While a program is executing, each ATR contains 
the number of a real memory page occupied by the program. The program 
“sees” these pages as contiguous because the program only uses translated 
addresses to refer to the pages. Every time the program references a memory 
location, address translation hardware uses the array of ATRs to generate the 
correct real memory address for that location. A close look at the translation 
process reveals some important details about S/36 memory management. 

Figure 2.5 shows what happens during real address generation. The 
translated address is three bytes long, but only the last two bytes contain 
address information. The first byte is always set to “10000000,” where the 
high-order “1” identifies this address to the MSP hardware as one requiring 
translation. The seven bits following the “1” are ignored in a translated 
address. The sixteen remaining address bits provide an address space of 
65,536 bytes, or 64 K. (This limit of using only two bytes for address informa- 
| tion is the origin of the infamous 64 K region-size limitation.) 

Because the last eleven bits of the translated address always fall with- 
in the boundaries of one logical page (the largest number represented by 
11 bits is 2,047), these eleven bits are copied directly into the corresponding 
eleven bits of the generated real address. 

The first five bits of the sixteen-bit translated address represent the 
number of the ATR containing the real memory page frame address. In the 
WM example, these bits contain “00101,” or five, causing ATR #5 to be selected. 
MAMI Each ATR is sixteen bits long, but only twelve of those bits are used. Those 
WNIT twelve bits are copied to bits 1 through 12 of the generated real address. Bit 0 
MAKI of the generated real address is forced to a value of zero, which as previously 
Mil mentioned, designates a real address. This “generated” real address is the actu- 
MII al location of the data in real memory. 

Mill The S/36 performs the address translation process automatically for 
HN | every machine instruction. When a machine instruction references several 
Ml translated addresses, each address is individually translated as it is needed. For 
Mil example, if the instruction resides in translated memory (as is usually the 
case), the instruction address is translated just before the instruction is fetched. 
i If the instruction then references operands in translated memory, each 
| operand address is translated individually before the operand is used by the 
instruction. Because the translation is carried out in hardware, the process 
Ml does not add significant time to program execution. 

Mh The S/36 address translation mechanism not only solves the memory 
fragmentation problem, it also lets program pages reside in memory in any 
order. In fact, the system can even change the page order in memory, provided 
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Figure 2.5 
Example of Generating a Real Address 
From a Translated Address 


Translated address 
DO 8 


Bits 1-7 are 
always Zero. 
They are unused. 


Bit 0 is always a 
“1” for translated 
addresses. 


MO—|COBDNMNPWNH—$O 


a 


Generated real address 





the ATR array for the moved pages is updated to reflect their new location. The 
useful ability to change page order without affecting the programs involved 
makes possible the next feature of $/36 memory management: virtual memory. 


Virtual Memory 

The fact that two levels of storage — primary and secondary — exist in most 
computer systems points up an ongoing compromise in computer technology. 
High-speed primary storage (such as the S/36’s solid-state main memory) is 
too expensive and volatile for permanent data retention, so permanent infor- 
mation is stored on less expensive, but slower, secondary storage (usually 
disk). Primary storage. contains only the data and programs the computer cur- 
rently needs. However, the computer often works on several programs simul- 
taneously — perhaps more than can fit in main memory at one time. When 
the number of currently executing programs exceeds the capacity of main 
memory, main memory is overcommitted. One way to handle overcommit- 
ment is to hide the true size of main memory from programs, letting them 
believe that there is much more memory than actually exists. The memory that 
programs use during execution — but that may not actually be available on 
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the system — is called virtual memory (VM). The range of “imaginary” 
addresses is the virtual address space. 

There are two popular ways to implement VM: segmented paging and 
demand paging. Figure 2.6 compares some features of segmented paging used 
by the S/36 with demand paging used by the S/38 and the AS/400. As you can 
see from the chart, neither technique is new. Both techniques originated in the 
early sixties and both share three important characteristics: memory organiza- 
tion, backup storage method, and address translation method. Both techniques 
also make tradeoffs involving expense, performance, and efficiency. 


Page-in, Page-out Mechanisms 

With demand paging, programs can reference any location in the virtual 
address space directly, although only some of the pages of the virtual address 
space actually reside in real memory at any one time. When a program tries to 
reference a location in a page not currently resident in real memory, special 
hardware detects the condition and generates a page fault interrupt. The page 
fault interrupt invokes a special operating system routine or hardware device 
to locate the requested page on secondary storage and read it into real memo- 
ry, a process called paging in. 

As part of the page-in process, the page fault handler updates a table 
used to generate real addresses during program execution — a process similar 
to S/36 address translation. To make room for the page to be read in, the page 
fault handler also may need to select a less important page in real memory 
and write it to secondary storage, a process called paging out. Usually, the 
paged-out page is chosen using an algorithm that finds the least-recently-used 
page in real memory. 

The term demand paging comes from the fact that paging is driven 
by program references, or demands, to virtual memory. If a program never 
asks to “see” any location on a particular page, the page is never brought into 
real memory. 

Segmented paging does not allow programs direct addressability to all 
locations in the virtual address space. Instead, programs have access only to a 
segment of virtual memory — 64 K in the case of the S/36. Instead of waiting 
for a program to reference a location in a nonresident page, the operating sys- 
tem keeps a list of pages currently being used by each executing program. 
When control switches from one program to another, the operating system com- 
pares the list of pages the next program requires with a list of pages currently in 
real memory (the virtual page table). If any pages are missing, the operating sys- 
tem retrieves them from secondary storage. If there are no free pages in real 
memory, the operating system writes some least-recently-used pages to sec- 
ondary memory to free up enough pages for the next program to run. 

The primary advantage of segmented paging — inexpensive imple- 





First implemented 


Memory organization | Fixed-length pages (2,048 bytes on the 
$/36) 


Backing store 


Address translation | Dynamically with dedicated hardware. 


Page-in mechanism 
Page-out mechanism 
Real memory usage 
Implementation 

Best features 


Worst features 








Figure 2.6 
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Segmented and Demand Paging Comparison 


Segmented paging (S/36) 


Burroughs B5000, 1961 


Operating system knows program 
Tequirements and brings in required 
pages before giving program control. 


Pages for the lowest priority tasks are 
written out until enough pages are avail- 
able for the program waiting for storage. 


All pages for which a program has 
addressability must be in real storage 
before the program can run, regardless 
whether the program actually needs data 
in those pages now. 


Mostly software. Address translation is 
assisted by special hardware. 


Simplicity; lack of specialized hardware 
makes implementation less expensive; 
performance does not depend upon pro- 
gram behavior. 


Lack of hardware assistance means 
greater execution overhead; large pro- 
grams tend to squander memory because 
unneeded pages are kept resident. 





Demand paging (S/38 and AS/400) 
Atlas, 1962 


Fixed-length pages (512 bytes on the 
$/38; 4096 bytes on the AS/400) 


Secondary disk storage 
Hardware detects program request for 
nonexistent page and generates a “page 


fault” to bring page in before task 
resumes execution. 


The least-recently-used page is written 
out and used to satisfy the page fault 
request. 


Only pages actually referenced by a pro- 
gram need be kept in real storage. 
Unused pages eventually are moved to 
secondary storage, freeing real storage 
for other programs. 


Mostly hardware. Page faults and content 
management have special hardware 
assistance. Address translation is per- 
formed entirely in hardware. 

Hardware implementation improves both 
time and space efficiency; because only 
referenced pages are resident, memory 
utilization is good. 

Hardware implementation is expensive; 
certain kinds of program behavior can 
cause repeated paging, known as 
“thrashing,” which degrades performance. 


mentation — comes from the fact that less complex address translation hard- 
ware is required. On the S/36, the address translation mechanism already is in 
place, making it easy to move pages in and out of real memory and rearrange 
them when necessary. 

However, the inexpensive implementation exacts a price in perfor- 
mance. All the pages used by a program must be brought in before the pro- 
gram can resume execution, so some pages probably are not needed, and are 
wasted. Also, the special hardware used by demand paging to detect missing 


— 
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ing external pro- 
gram calls (EPC) 
itly reduces task 
Initiation and file 





pages usually is much faster than the software-implemented virtual page table 
the S/36 uses for segmented paging. 

On the S/36, this performance loss is mitigated to some extent, 
because the CSP can perform VM management chores while the MSP is work- 
ing on user programs. But segmented paging also imposes a restriction on 
programmers: programs cannot exceed the size of one segment. On the S/36, 
the hardware-limited, 64 K segment size is uncomfortably small. Some systems 
other than the S/36 use a segmented paging approach that allows a program 
to use more than one segment, thus alleviating the S/36 restriction. 

VM does, however, achieve its purpose. It theoretically can manage a 
virtual address space of 128 MB — 16 times larger than the maximum real 
address space of 8 MB. And it can manage this large virtual space efficiently. 
Many S/36 installations use external program calls to activate all of their fre- 
quently run programs for each user at the beginning of the day — hundreds 
of simultaneously active program segments amounting to 20 MB or more of 
VM. Because paging is much faster than reinitiating programs and reopening 
files, this technique eliminates redundant program initiation, reduces file open 
and close overhead, and improves response time dramatically. 


Peculiarities of S/36 VM 

The S/36 VM mechanism has a few unusual, and potentially confusing, twists. 
One common misconception is that the 64 K segment-size limitation, which 
also limits program size, limits task size. A task can contain one or more pro- 
grams, each of which can be up to 64 K and must be executed individually. 
Because the number of programs that can be contained in a task on the $/36 
is unlimited, the size of a task is also unlimited (up to the size of virtual 
address space). 

The S/36 contains a built-in external program call mechanism that lets 
one program invoke another separately compiled program, and then regain 
control when the called program returns. In addition, any number of called 
programs contained within a task may be simultaneously active. Active pro- 
grams retain their internal state (values of variables and open files) from invo- 
cation to invocation. 

Another oddity of the S/36 virtual implementation is the concept of 
workspaces, virtual segments that contain data instead of program code. 
Workspaces hold data buffers, screen formats, and various system-related 
tables and work areas, helping you get around the limitations of 64 K per pro- 
gram. An example of a workspace familiar to RPG programmers is the disk file 
workspace, which is created automatically when the 64 K segment for an RPG 
program has no room for disk file physical I/O buffers. 

When a program needs to access data in a workspace, it calls on the 
operating, system map facility, which gives the program addressability to the 


— _ el 
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workspace by giving up some addressability to the program’s virtual segment. 
Mapping, however, takes time and may result in paging activity, so the 
increased flexibility gained using workspaces is purchased with reduced per- 
formance. 

A third unusual $/36 VM artifact is encountered only by installations 
that use a large amount of VM. On the S/36 the secondary storage used for 
paging is called the Task Work Area (TWA). The TWA is contained in a spe- 
cial system file called #SYSTASK that must reside on drive A1. 

Initially, the maximum size for #SYSTASK is 6553 blocks (16 MB). 
This maximum is only about twice the maximum real memory size of 8 MB — 
not a very efficient overcommitment ratio. When the TWA is full, the SSP auto- 
matically extends the TWA by 400 blocks. When the TWA fills again, SSP dou- 
bles the extension to 800 blocks. Each time the TWA fills up, the size of the 
extension is doubled, allowing the TWA to grow to a very large size. 

Unfortunately, each TWA extension requires contiguous space on 
drive Al. Drive A1 is also the default drive the system uses when allocating 
new files and work areas, which results in disk space fragmentation that may 
prevent the TWA from extending. Thus, the difficulty of obtaining disk space 
for paging can result in a much lower virtual address space limit than the 
128 MB architectural maximum, unless the user takes steps to force TWA 
expansion before the A1 disk space becomes fragmented. 


System Queue Space 

Now that you understand real, translated, and virtual memory, you can appre- 
ciate the effort undertaken by the S/36 to administer memory usage efficiently. 
Although address translation and segmented paging improve memory use by 
effectively reusing a limited resource, not everything in real memory can be 
moved about with abandon. Only objects in the user area accommodate this 
manipulation. A certain amount of real memory — the fixed and variable 
nuclei — must remain resident and can be accessed only through real 
addressing. 

All of the fixed nucleus and most of the variable nucleus is static 
(unmoving) — beyond your control. As mentioned earlier, programming tech- 
niques directly affect only one part of the variable nucleus: system queue 
space. Knowing how your application design decisions impact SQS use helps 
you make educated compromises between performance and simplicity. 

SQS is an expandable “pool” of memory used by the SSP and the CSP 
to hold dynamically allocated data structures, called control blocks, critical to 
the operation of the system. Once a control block is created in SQS, it remains 
resident in real memory at the same location until explicitly destroyed. 
Because each control block must occupy contiguous memory locations, SQS 
can become fragmented. 


Performance Tip 


One way to reduce TWA 
expansion problems is 
to “pre-allocate” the 
TWA by activating all 
your programs in 
advance — usually 
immediately after IPL 
(see Chapter 7). 
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Control blocks range in size from 16 bytes to 2,048 bytes, in 16-byte 
increments. They can be categorized by their life spans: short, medium, and 
long. A short-lived control block’s life span is only a few milliseconds. The SSP 
creates short-lived control blocks for the duration of certain brief chores (e.g., 
a disk file operation) and destroys them when the chore is complete. Medium- 
lived control blocks last a relatively long time — for the duration of a job, for 
instance. Long-lived control blocks (usually created when the system is start- 
ed) are the very few that become permanent until the next IPL. 

The system keeps a modest reserve of SQS available (about 2000 to 
4000 bytes) to satisfy most control block creation requests quickly. When this 
reserve is consumed, the system takes a 2 K page away from the user area 
and adds it to SQS. (Because a control block cannot be larger than 2 K bytes, 
the newly acquired page can be obtained from anywhere in real memory.) 
The system continues to take 2 K pages from the user area as needed. When 
more than about 4000 bytes accumulates in the SQS reserve area (due to con- 
trol blocks being freed), the system returns a 2 K page to the user area. Thus, 
the logical “boundary” between SQS and the user area fluctuates constantly to 
meet the needs of the system. 

Of the three classes of control blocks, only one is of concern to you. 
Short-lived control blocks have minimal impact on system performance, and 
long-lived control blocks are beyond your control. Only medium-lived control 
blocks have a controllable impact on system performance; most medium-lived 
control blocks are a direct result of the kinds of programs you design. The 
table in Figure 2.7 summarizes the space requirements for the most common 
control blocks and the program activities that create them. 

The table also will help you determine the amount of SQS a given 
program or device needs to run. Computing the SQS requirements for an 
entire job mix lets you estimate the total amount of real memory that will be 
dedicated to SQS, and therefore will be unavailable in the user area. For 
example, an interactive job with ten indexed files, a printed report, and five 
subprograms requires 9,088 bytes of SQS: 


© 192 bytes for the workstation session control block 

* 256 bytes for the job control block 

© 96 bytes for the task control block 

320 bytes for the active programs (64 bytes each) 

© 96 bytes for one level of subprogram invocation 

° 64 bytes for a disk file workspace 

° 688 bytes for the opened print file 

© 1,600 bytes for disk file VTOC entries (160 bytes each) 

© 1,680 bytes for other file-related control block (file specification block, file 
buffer block, disk buffer block, allocation queue element, record queue 
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Figure 2.7 
System Queue Space Requirements for Common Control Blocks 






Total SQS 
SSP entity Control Block Bytes Used 


Fach acl wonton sess i 
ch pin e 
Fah ot dvs o 
Fah 26 
Fach ak % 
Fah ae poem or roan a 
Each invoked program or subprogram 96 (avg) 
Fach woe 4 
Each user of an opened file File Specification Block (64 bytes) 

File Buffer Block (24 bytes) 104 


Disk Buffer Block (16 bytes) 


Additional overhead for first user 
to open a file or use a library 


Additional overhead for each user Allocation Queue Element (32 bytes) 
of a shared file Record Queue Block (16 bytes) 


Additional overhead for each user 
of an indexed file 


Each storage indexed file storage index | Depends on the size of a storage index oie 
(the storage for a file is shared by all users of the file) 


Each opened print file being spooled Printer Specification Block (64 bytes) 
Spool File Descriptor (112 bytes) 688 (avg) 
Spool intercept buffer (256-2048 bytes) 
Writer Descriptor Block (48 bytes) 
Task Block (96 bytes) 

Spool print buffer (256-2048 bytes) 


Format-1, or VTOC entry (160 bytes) 160 









Index Control Block (16 bytes) 16 


& 


Each active spool writer 
1168 (avg) 


block, and index control block) , and 
e 4,096 bytes for storage indexes (estimated) 


If you plan to run the program from nine workstations simultaneous- 
ly, the additional eight workstations require 3,392 bytes of SQS each (the 
VTOC control blocks and storage indexes are counted only for the first user), 
resulting in a grand total of 36,224 bytes of SQS. Remember that SQS use 
reduces the amount of memory available in the user area for virtual use, there- 
by increasing the “swap rate” (level of paging activity), and possibly degrading 
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system performance. If you run these programs on a 512 K system, you might 
find installing another 256 K memory board a cost-effective way of maintain- 
ing acceptable response time. 

Considering all aspects of S/36 memory management, you can see why 
misconceptions abound. But the S/36 loses its mystique once you master the 
| secrets of its memory. You can use this knowledge to help plan future expan- 
| sion of your S/36 and to evaluate its place in the midrange system market. Care- 
i ful evaluation of memory requirements lets you predict the effect of additional 
HI memory more accurately. And, of course, the better you understand your S/36, 
the better you can take advantage of its features to improve performance. 























































































































